mSRTM Sample

Description

This sample program, Multicore Response Time Measurement (mSRTM), runs a System Response Timer on different cores simultaneously. It measures the difference between the expected timer interval and the actual timer interval.

Each core has its own timer and its own thread allocation memory to support the timer function. The core thread creates the timer and the necessary resources, and then waits for the main thread to initiate the test with a semaphore to synchronize all cores as closely as possible, though the test does not synchronize results.

Source Files

File	Description
mSrtm.cpp	Gathers thread-level timer latencies (either as a Win32 or RTSS process) and prints out a summary and an optional histogram of results. The timer can also generate a sound on the speaker. This is a useful tool for measuring application-level response time latencies while the system is stressed by other activity, such as disk, network, and GUI IO, and/or heavy processing. Different hardware platforms can also be compared.
mSrtm_funcs.cpp	Additional helper functions.
mSrtm.h	Header file.

Building the Sample

Build the sample as is. See Usage for additional options.

Running the Sample

Run the sample as is. See Usage for additional options.

Usage

mSrtm | mSrtm [/?] [/h] [/s] [/1] [/f] [c] [/p x y] seconds_to_sample

Options

/h

Display histogram (in addition to summary)

/s

Turn on sound (square wave driven by timer)

/1

Use a 10 MS timer period (default is 1 MS)

/f

Use fastest available timer (1MS or better)

/c

Use RtGetClockTime to measure

/p x y

Specify the first and last processors to use (x = first, y = last)

seconds_to_sample

Duration in seconds to sample timer response latencies.

/?

Help on usage

If no parameters are given, the default is mSrtm /h /s /f 15, and timing is done on the first RTSS processor.

Remarks

The mSRTM program can be built as a Win32 .exe or real-time .rtss executable file.

The mSRTM program differs from the SRTM program in that mSRTM measures the timer periodic interval deviation from the set value, while SRTM measures the timer response latencies including APIC timer drift.

The RTSS timer periodic interval deviation observed by an application is made up of the following:

• deviation in Hardware latency
• the time it takes for a signal to be recognized by the HAL Interrupt Service Routine (ISR)
• the deviation in Software latency
• the time it takes from ISR to the routine running in IST

The major source of Hardware latency is System Management Interrupt (SMI) and bus contention between Windows cores and RTSS cores. To mitigate the side effects of Hardware latency on RTSS timer latency and RTSS time, RTX64 uses a timer tick compensation algorithm. This algorithm uses the two Time Stamp Count (TSC) readings between previous and current ISR to calculate the number of ticks. ISR then uses the calculated number of ticks (instead of 1 tick) to check user timer expiration and to increment RTSS time. If SMI or bus contention occurs at the early stage of the user timer period, its handling routine will be called on time. If occurring at the later stage, the current call is later, but the subsequent call will be on time because of reduced ticks to expire.

mSRTM calculates timer periodic interval deviation by subtracting the expected interval from the actual interval measured by calling QueryPerformanceCounter or RtGetClockTime. Without timer tick compensation, the time obtained by RtGetClockTime may be slower when compared with universal time. However, because RTSS time always increments by 1 tick, such time drift is not reflected in the interval measured by RtGetClockTime. Therefore, mSRTM results measured by RtGetClockTime may not fully reflect the side effect of SMI or bus contention. While the results measured by QueryPerformanceCounter fully reflect the side effect of SMI or bus contention. With tick compensation, the time obtained by RtGetClockTime is much closer to the universal time. Therefore, even measuring with RtGetClockTime, mSRTM results will fully reflect the side effect of SMI or bus contention.

In RTX64 4.1 and later versions, timer tick compensation is the default configuration. Timer tick compensation will decrease the occurrence of jitters in user timer periodic intervals, but it will not reduce the absolute value of jitters (such as when SMI or bus contention occurs at the last tick of user timer period). This may be apparent in the mSRTM results.

If you already have a workaround for timer latency jitters, see the TechNote Real-Time Subsystem Timer Tick Compensation for instructions on how to disable timer tick compensation.